第25期吐槽:PG的物理Standby无法Partial导致单元化架构/SaaS使用不灵活
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第25期吐槽:PG 不支持物理Partial Standby
1、产品的问题点
PG 不支持物理Partial Standby. 例如主实例有10个database分别对应10个跨省子数据库, 如果采用物理standby, 不能从中心库分别选择1个同步到不同的省份本地机房实例.
2、问题点背后涉及的技术原理
PG 通过全量数据+wal日志增量回放可以创建近乎实时的物理从库, 但是主库和从库的数据文件必须一致, 暂时不支持创建只有部分数据的standby
3、这个问题将影响哪些行业以及业务场景
集团或中心+子节点的组织架构类业务, 例如全国库(最大), 省份库(其次), 地市库(最小).
将单一数据库拆分成多个数据库
将多个数据库合并成1个大实例
4、会导致什么问题?
不支持parital standby, 那么就只能建立完整的从库, 可能无法满足权限诉求, 例如不同的省份应该同步不同的数据.
即使只需要部分数据, 但是也需要建立整个实例的从库, 需要耗费更多的存储空间.
5、业务上应该如何避免这个坑
使用逻辑复制代替物理复制, 逻辑复制可以做到表甚至tuple级别
使用外部插件或软件walbouncer
不活跃,也没有在生产验证过
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
逻辑复制有前置依赖, 需要PK或UK.
逻辑复制的效率低于物理流复制(由于逻辑复制需要在事务结束后才能解析WAL, 对于大事务延迟更高.)
7、数据库未来产品迭代如何修复这个坑
期待内核层按database或schema隔离wal，并且支持物理partial standby
支持单个standby能接收多上游的wal合并成大库.
- 感觉可能有点像o pdb
本期彩蛋-招商中,有需要的小伙伴可联系嵌入...
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: